MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 117

Text File | 1995-10-21 | 102KB | 2,775 lines

C.S.M.P. Digest             Sat, 21 Oct 95       Volume 3 : Issue 117

Today's Topics:

        Can I use my own values in the windowKind field?
        Changing monitor resolution on the fly.
        Confessions of an LDEF writer
        Drag Mgr. Question: Confining drags to a window
        Drag and drop on Finder aliases
        Find vertical extent of call to TextBox?
        Gestalt Selectors List 3.1
        Help with UniversalProcPtrs
        How to detect if the cap-lock is on?
        How to tell if a volume is busy ?
        Killed By Update Events (again)
        Making TextEdit field a one-liner
        MixedMode Manager Routine Descriptors for SetDialogItem calls?
        Photoshop Filter Host?
        PowerPC handling of preloaded CODE resources?
        Printing a Hairline?
        [FAQ?] Saving GWorld to PICT...
        [Q] How to use SetDialogTracksCursor()



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Chris Watson)
Subject: Can I use my own values in the windowKind field?
Date: Sun, 24 Sep 1995 21:04:41 -0400
Organization: Communications Accessibles Montreal, Quebec Canada

The subject says about everything... Can I use my own value in the
windowKind field of the WindowRecord?  I'd like to do this so I know what
kind of window I'm dealing with.

Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
contain one of two constants: dialogKind or userKind".  It also states,
"The value userKind represents a window created by your application."  I
am led to conclude that I cannot use my own values here.

I saw a thread not long ago discussing this, but saw conflicting answers.
I know I can't use negatives (those are for DAs) and I can't use
dialogKind (2) or userKind (8)... How about all those other numbers?  Such
as those above 8.

Thanks for any help!

=====================================================================
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  H H      |                   |                                       |
  | |      | Sean McBride      |                                       |
H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
  | |      | Montreal, Canada  |                                       |
  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 25 Sep 1995 09:23:49 GMT
Organization: LMC-IMAG Grenoble France

In article <[e-mail]>, [e-mail]
(Chris Watson) wrote:

>The subject says about everything... Can I use my own value in the
>windowKind field of the WindowRecord?  I'd like to do this so I know what
>kind of window I'm dealing with.
>Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
>contain one of two constants: dialogKind or userKind".  It also states,
>"The value userKind represents a window created by your application."  I
>am led to conclude that I cannot use my own values here.
>I saw a thread not long ago discussing this, but saw conflicting answers.
>I know I can't use negatives (those are for DAs) and I can't use
>dialogKind (2) or userKind (8)... How about all those other numbers?  Such
>as those above 8.

Hi Sean,
i've never tried to modify the windowKind field of a WindowRecord.
The usual way to specify the kind of window is to
use the refCon field, reserved for that, and presents in the
NewWindow (or NewCWindow, ...) parameter list.

HTH
Fr
- -------------------------------------------------------------------------------------
FR Degott ([e-mail])
LogiMath, Lab. LMC-IMAG - Grenoble - France
- -------------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Mon, 25 Sep 1995 13:33:44 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>, [e-mail]
(Chris Watson) wrote:
>
> The subject says about everything... Can I use my own value in the
> windowKind field of the WindowRecord?  I'd like to do this so I know what
> kind of window I'm dealing with.
>
> Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
> contain one of two constants: dialogKind or userKind".  It also states,
> "The value userKind represents a window created by your application."  I
> am led to conclude that I cannot use my own values here.
>
> I saw a thread not long ago discussing this, but saw conflicting answers.
> I know I can't use negatives (those are for DAs) and I can't use
> dialogKind (2) or userKind (8)... How about all those other numbers?  Such
> as those above 8.

In the TCL (at least version 1.x.x) the window's refCon was used to store
a copy of the window object's handle while the windowKind field was
set to 'CW' or something like that (ie a short) so that the TCL-based
application would "know" which windows were objects and which were not.

So I guess you can use it - say 'MW' for "my window", freeing up the
refCon field for a handle or pointer, but it's probably not recommended
- the usual disclaimer about undocumented uses not being guaranteed to
work with future OS changes etc....

Dave Stone

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 25 Sep 1995 13:46:05 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Chris Watson) wrote:

<The subject says about everything... Can I use my own value in the
<windowKind field of the WindowRecord?  I'd like to do this so I know what
<kind of window I'm dealing with.
<
<Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
<contain one of two constants: dialogKind or userKind".  It also states,
<"The value userKind represents a window created by your application."  I
<am led to conclude that I cannot use my own values here.
<
<I saw a thread not long ago discussing this, but saw conflicting answers.
<I know I can't use negatives (those are for DAs) and I can't use
<dialogKind (2) or userKind (8)... How about all those other numbers?  Such
<as those above 8.
<
<Thanks for any help!
<
<=====================================================================
<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<  H H      |                   |                                       |
<  | |      | Sean McBride      |                                       |
<H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
<  | |      | Montreal, Canada  |                                       |
<  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Yes Sean.  You can place any value above 8 in the windowKind field in your
custom document windows.

____________________________________________________________________
Brian  Stern  {8-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash
INIT Writing FAQ etc. at <ftp://ftp.pbcomputing.com//Guests/BrianS/>

+++++++++++++++++++++++++++

>From [e-mail] (john elemans)
Date: 25 Sep 1995 18:07:08 GMT
Organization: hundred peaches inc

Francios' suggestion is okay, except if you are using the refcon for
something else. In that case it is fine to set the windowkind to what ever
you like.

I use the Window kind to hold a code and then use the refcon for
an object handle (using think c). This way I can check the window
kind and know what the class of the object which created the
window. Then I can coerce the refcon to the right class and
use the object to perform the window operations.

je

In article <[e-mail]>,
[e-mail] (F. Degott) wrote:

> In article <[e-mail]>, [e-mail]
> (Chris Watson) wrote:
>
> >The subject says about everything... Can I use my own value in the
> >windowKind field of the WindowRecord?  I'd like to do this so I know what
> >kind of window I'm dealing with.
> >Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
> >contain one of two constants: dialogKind or userKind".  It also states,
> >"The value userKind represents a window created by your application."  I
> >am led to conclude that I cannot use my own values here.
> >I saw a thread not long ago discussing this, but saw conflicting answers.
> >I know I can't use negatives (those are for DAs) and I can't use
> >dialogKind (2) or userKind (8)... How about all those other numbers?  Such
> >as those above 8.
>
> Hi Sean,
> i've never tried to modify the windowKind field of a WindowRecord.
> The usual way to specify the kind of window is to
> use the refCon field, reserved for that, and presents in the
> NewWindow (or NewCWindow, ...) parameter list.
>
> HTH
> Fr
>
- -------------------------------------------------------------------------------------
> FR Degott ([e-mail])
> LogiMath, Lab. LMC-IMAG - Grenoble - France
>
- -------------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Ola Berg)
Date: 25 Sep 1995 20:18:09 GMT
Organization: Digit

In article <[e-mail]>, [e-mail]
(Chris Watson) wrote:

>The subject says about everything... Can I use my own value in the
>windowKind field of the WindowRecord?  I'd like to do this so I know what
>kind of window I'm dealing with.
>Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
>contain one of two constants: dialogKind or userKind".  It also states,
>"The value userKind represents a window created by your application."  I
>am led to conclude that I cannot use my own values here.
>I saw a thread not long ago discussing this, but saw conflicting answers.
>I know I can't use negatives (those are for DAs) and I can't use
>dialogKind (2) or userKind (8)... How about all those other numbers?  Such
>as those above 8.

Do not change windowKind. It is good to have when mac is separating dlogs
from winds.

Use SetRefCon( WindowPtr, long refcon)

and

long refcon = GetRefCon( WindowPtr) instead!

With GetWVariation() you also get wich kind of window defproc that you are
using. It is good for handling the size-box. I think. Email me if that is
stupid cos I rely on this everytime!


Yours in HIM

<ichtys><

Ola
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 26 Sep 1995 03:17:55 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (john elemans) wrote:

<Francios' suggestion is okay, except if you are using the refcon for
<something else. In that case it is fine to set the windowkind to what ever
<you like.
<
<I use the Window kind to hold a code and then use the refcon for
<an object handle (using think c). This way I can check the window
<kind and know what the class of the object which created the
<window. Then I can coerce the refcon to the right class and
<use the object to perform the window operations.
<

Exactamundo.

Let me quote from IM I.

[It mentions that the windowKind field may be negative, 2 or 8.]

"UserKind represents a window created directly by application calls to the
Window Manager; for such windows the application can in fact set the
window class to any value greter than 8 if desired."

____________________________________________________________________
Brian  Stern  {8-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash
INIT Writing FAQ etc. at <ftp://ftp.pbcomputing.com//Guests/BrianS/>

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Tue, 26 Sep 1995 10:03:44 -0800
Organization: Altura Software, Inc.

> The subject says about everything... Can I use my own value in the
> windowKind field of the WindowRecord?  I'd like to do this so I know what
> kind of window I'm dealing with.
>
> Inside Mac says (NIM:Macintosh ToolBox Essentials, 4-67) "This field can
> contain one of two constants: dialogKind or userKind".  It also states,
> "The value userKind represents a window created by your application."  I
> am led to conclude that I cannot use my own values here.
>
> I saw a thread not long ago discussing this, but saw conflicting answers.
> I know I can't use negatives (those are for DAs) and I can't use
> dialogKind (2) or userKind (8)... How about all those other numbers?  Such
> as those above 8.

I think it's safe to use any positive number for windowKind. However, I
believe dialogs must have dialogKind.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Coming to you fast as lightning on a 9500/120!

+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Tue, 26 Sep 1995 12:53:37 -0400
Organization: Communications Accessibles Montreal, Quebec Canada

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> "UserKind represents a window created directly by application calls to the
> Window Manager; for such windows the application can in fact set the
> window class to any value greter than 8 if desired."

Well, there have been lots of replies to my orignal post and almost all of
them have completely different answers, but, for me this settles it... I
wonder why this little tidbit of information appears no where in New
Inside Mac (that I've found anyway)

Thanks to all for helping out!  It is truely appreciated!

=====================================================================
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  H H      |                   |                                       |
  | |      | Sean McBride      |                                       |
H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
  | |      | Montreal, Canada  |                                       |
  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

+++++++++++++++++++++++++++

>From [e-mail] (Peter Bromley)
Date: Fri, 29 Sep 1995 16:51:36 +1200
Organization: ADInstruments

In article <[e-mail]>, [e-mail]
(Chris Watson) wrote:

> In article <[e-mail]>,
> [e-mail] (Brian Stern) wrote:
>
> > "UserKind represents a window created directly by application calls to the
> > Window Manager; for such windows the application can in fact set the
> > window class to any value greter than 8 if desired."
>
> Well, there have been lots of replies to my orignal post and almost all of
> them have completely different answers, but, for me this settles it... I
> wonder why this little tidbit of information appears no where in New
> Inside Mac (that I've found anyway)
>
> Thanks to all for helping out!  It is truely appreciated!


What I find interesting is that this 'little titbit of information' didnt
make the jump from IM to NIM. Does this indicate a hidden agenda on Apples
behalf ;-)
MAYBE the windowKind will quietly disappear some time soon (did I hear
someone say Copland?).

--
-
Peter Bromley                                  ([e-mail])
ADInstruments, Dunedin, New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Sun, 01 Oct 1995 14:07:28 -0400
Organization: Communications Accessibles Montreal, Quebec Canada

In article <[e-mail]>, [e-mail]
(Peter Bromley) wrote:

> What I find interesting is that this 'little titbit of information' didn't
> make the jump from IM to NIM. Does this indicate a hidden agenda on Apples
> behalf ;-)
> MAYBE the windowKind will quietly disappear some time soon (did I hear
> someone say Copland?).

Perhaps, but I just finsihed changing my code to make use of the
windowKind field and everything does work as before....

BTW, Windows.h does have a SetWindowKind () so at least it seems that we
are allowed to use it for the time being...


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  H H      |                   |                                       |
  | |      | Sean McBride      |                                       |
H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
  | |      | Montreal, Canada  |                                       |
  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---------------------------

>From [e-mail] (Summerall  Thomas G)
Subject: Changing monitor resolution on the fly.
Date: 2 Oct 95 19:21:34 GMT
Organization: University of Colorado at Boulder

I've just discovered that  with a multisync monitor and the appropriate
adapter, PowerMacs can change screen pixel resolution immediately, without
rebooting, via the monitors control panel.  This is a joy because we often
want to be in 640X480 to look at graphics in their final foprm, but then
switch to a higher res for looking at a lot of stuff at once.

So, my question is, how could I find out how the monitors control panel does
this and then implement it in a QuickKey or faceless app?   I can't find
anything about this ability in the device manager documentation.  Is it
documented?   If so where?  If not, does anyone know how to do this?

If I figure it out, I'll release it as free/shareware depending on how
difficult it is.

Thanks!

Tom Summerall

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 4 Oct 1995 01:01:21 GMT
Organization: First Ascent

In article <[e-mail]>
[e-mail] (Summerall  Thomas G) writes:

> So, my question is, how could I find out how the monitors control panel does
> this and then implement it in a QuickKey or faceless app?   I can't find
> anything about this ability in the device manager documentation.  Is it
> documented?   If so where?  If not, does anyone know how to do this?

Yes. It's in the QuickTime 2.1 API.


Alex Curylo  [e-mail]  [phone], fax -1359
***  First Ascent: Mac programming, UP paragliders, indie CDs  ***

---------------------------

>From [e-mail] (Thomas L. Perry)
Subject: Confessions of an LDEF writer
Date: 30 Sep 1995 18:25:51 GMT
Organization: Bullfrog Software Engineering

    On a recent project I decided that it was time to give all my
dialogs that gun metal grey slick 3D interface that seems to be very
popular these days. The first part of this task, was to change the
dialog background color to grey. That was trivial, however, it
introduced some new, and not completely unexpected problems (as I have
read from others in this newsgroup a few times).
    The key to this lovely grey interface is that some of the controls
still need to have a white background such as text boxes and scrolling
List boxes. The solution for most of the controls was easy, I simply
changed the 'cctb' for the relevant controls. However, for my
listboxes, the solution was not nearly so convenient (go ahead and
correct me if I'm wrong).
    To get the white fill in the listboxes I had to write my own LDEF
so that I could control the drawing of the listbox background. That
wasn't too tough, I just handle the lDrawMsg and draw a white box
behind each item in the list. So there I had it, problem solved, right?

    As I am patting myself on the back and scrolling down my list I
discover that the very last item in the list scrolls upward to reveal
an extra space that I had never allocated. Evidently, and much to my
chagrin, the list manager always adds one more element to your list
than the number that you have explicitly created. Unfortunately, this
extra space at the end is colored grey, and I can't seem to paint it
white.
    The bottom line is that my entire list draws beautifully, white
background and all, with the exception of the very last (empty) cell in
the list which appears grey. It looks pretty lame. How do I paint in
this last cell? Better yet, how can I eliminate this blank and useless
cell at the end of the list?

Sigh...
Tom Perry

|o|=============================================================|o|
|o|  Bullfrog Software Engineering      206.747.8199 vox        |o|
|o|  12700 N.E. 8th St. #E302           206.747.8299 fax        |o|
|o|  Bellevue, WA 98005                 [e-mail]  |o|
|o|=============================================================|o|

+++++++++++++++++++++++++++

>From [e-mail] (Harold Ekstrom)
Date: Sun, 01 Oct 1995 15:39:15 -0800
Organization: the ag group, inc.

Here's an alternative method: For windows that have a lot of white space
in lists or edit fields etc. leave the background color of the window
white and when you update the window make a region for the entire window
minus and items. FillRgn that area gray and then you don't have to do
anything with custom LDEFs or change control color tables.

Here's some tradeoffs:

gray background color
- items that are mostly white flash gray when they're being updated and
  there's no way to prevent this
- may require some special coding like custom LDEFs
- may require you to set up custom color tables for controls and other
  items


white background color
- the gray area flashes white while it's being updated (I think this is
  less annoying than other areas flashing gray partly because the white
  areas contain items that are probably the focus of the user's
  attention)
- requires you to be able to find all the items in the window and
  subtract them from a region to update the gray area (this may be easy
  if you can walk a simple list of items such as the DITL for a dialog)
- dialogs have a 3 pixel area around the edges that you cannot draw in
  and that is updated in the background color of the window (why the
  hell did they ever do that anyway?)

Overall I prefer the white background approach. The visual effect is more
pleasing and the gray area draws smoothly in one step without repainting.

-harold

- ------------------------------------------------------------
Harold Ekstrom
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp


---------------------------

>From David Reiss <[e-mail]>
Subject: Drag Mgr. Question: Confining drags to a window
Date: 29 Sep 1995 00:33:41 GMT
Organization: http://www.astro.washington.edu

Hi.  I am trying to write a DragTrackingHandler routine to confine
a drag within a window, much as the Drag Manager documentation suggests
you can do when it describes the 'SetDragMouse' routine.  It works
fine when the drag is over a window owned by my application, but
since my tracking handler doesn't get called when its over another
app, or over a finder window, the drag doesn't get confined in these
cases.  Does anyone know of a way to make SURE the drag is always within
my window, even when the cursor is NOT over a window from my application?
I suppose I could write a drag-drawing hook and use that, but then
I have to deal with the drag region drawing as well.  I'd prefer
to avoid that.  Thanks in advance for any -- and I mean any -- ideas!!!

-David Reiss
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Thu, 28 Sep 1995 21:51:52 -0800
Organization: Oracle Corporation

In article <44fet5$[e-mail]>, David Reiss
<[e-mail]> wrote:

> Hi.  I am trying to write a DragTrackingHandler routine to confine
> a drag within a window, much as the Drag Manager documentation suggests
> you can do when it describes the 'SetDragMouse' routine.  It works
> fine when the drag is over a window owned by my application, but
> since my tracking handler doesn't get called when its over another
> app, or over a finder window, the drag doesn't get confined in these
> cases.  Does anyone know of a way to make SURE the drag is always within
> my window, even when the cursor is NOT over a window from my application?
> I suppose I could write a drag-drawing hook and use that, but then
> I have to deal with the drag region drawing as well.  I'd prefer
> to avoid that.  Thanks in advance for any -- and I mean any -- ideas!!!

When you call AddDragItemFlavor, use the flavorSendOnly flag.  However,
it may just be easiest to blow off the Drag Manager and use
DragGrayRgn, since the Drag Manager isn't doing a whole lot for
you in this case.

-- Adam Winer
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chuck ...E's In Love... McMath)
Date: Fri, 29 Sep 1995 08:28:00 -0500
Organization: Reed Technology & Information Services, Inc.

In article <44fet5$[e-mail]>, David Reiss
<[e-mail]> wrote:

> Hi.  I am trying to write a DragTrackingHandler routine to confine
> a drag within a window, much as the Drag Manager documentation suggests
> you can do when it describes the 'SetDragMouse' routine.  It works
> fine when the drag is over a window owned by my application, but
> since my tracking handler doesn't get called when its over another
> app, or over a finder window, the drag doesn't get confined in these
> cases.  Does anyone know of a way to make SURE the drag is always within
> my window, even when the cursor is NOT over a window from my application?
> I suppose I could write a drag-drawing hook and use that, but then
> I have to deal with the drag region drawing as well.  I'd prefer
> to avoid that.  Thanks in advance for any -- and I mean any -- ideas!!!
>
> -David Reiss
> [e-mail]

Well, it looks like SetDragMouse will only work in pinning it within your
window.  The documentation doesn't say it'll actually constrict the
cursor, just that it allows you to pin the (proposed) drop location.

Can't you do something funky when you get the exitWindow and/or
exitHandler messages?  That's the only thing I can think of offhand.

Good luck, and why the heck do you even want to do this?  If it's special
data you can just use a special type, or maybe in your Drop Handler see if
the destination window != the source window and make the drag fail there.
While that's cheesy, it will have the effect of not allowing a person to
drag something from within your window to outside of it.

chuck

|-- Chuck McMath -- [e-mail] -or-- [e-mail] -----|
|-- Reed Technology & Information Services, Inc. -------------------|
|-- 20251 Century Blvd. -- Germantown, MD  20874 -------------------|
|-------------- "Hey Batter, Hey Batter, swing!" - Anon.------------|
|--------------- Jeans by Jordache, Body By Fritos -----------------|


+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 29 Sep 1995 16:48:41 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Adam
Winer, [e-mail] writes:

>However,
>it may just be easiest to blow off the Drag Manager and use
>DragGrayRgn, since the Drag Manager isn't doing a whole lot for
>you in this case.

This is what I do when it doesn't make sense to drag something outside
of a window.  Trying to use the Drag Manager in such a case would be
counter productive because it really wasn't designed for it.  It may
not even be possible.

+++++++++++++++++++++++++++

>From David Reiss <[e-mail]>
Date: 29 Sep 1995 22:11:43 GMT
Organization: http://www.astro.washington.edu

Actually, I just discovered how to do this using the drag manager last
night ( I want to use the drag manager because I already have drag-
response stuff like hilighting, etc. already designed, and I would
have to rewrite it if I were to use DragGrayRgn ).  Anyway, all you
have to do is use a custom DragInputProc routine, which allows you
to set the drag location for any drag originiating in your app, no
matter where the mouse cursor is.  So you just pin the drag location
within your window's rect, and all the drag feedback stuff works
fine.  Thanks for all the tips, but I think I'm gonna use this.  ANd
it works with PowerPlant's drag-and-drop classes too!

-David


+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Tue, 03 Oct 1995 11:07:33 -0500
Organization: ZERCOM Technologies Inc.

In article <44fet5$[e-mail]>, David Reiss
<[e-mail]> wrote:

> Hi.  I am trying to write a DragTrackingHandler routine to confine
> a drag within a window, much as the Drag Manager documentation suggests
> you can do when it describes the 'SetDragMouse' routine.  It works
> fine when the drag is over a window owned by my application, but
> since my tracking handler doesn't get called when its over another
> app, or over a finder window, the drag doesn't get confined in these
> cases.  Does anyone know of a way to make SURE the drag is always within
> my window, even when the cursor is NOT over a window from my application?
> I suppose I could write a drag-drawing hook and use that, but then
> I have to deal with the drag region drawing as well.  I'd prefer
> to avoid that.  Thanks in advance for any -- and I mean any -- ideas!!!
>
> -David Reiss
> [e-mail]

A simpler solution (and maybe even more convenient to the user) would be
to use application-specific flavors in your drags, and avoid using
standard flavors that may be used by other applications.  A flavor using
your application creator isn't a bad choice.

This would keep the data for yourself, but still allow your user to drop
the data into the Finder trash (thus, erasing the data if you handle this
correctly).

On this note, is there a drag flavor registry??  (why couldn't they use
AEs for this...)

Martin-Gilles Lavoie

- -------------------------------------------------------------------
MPW: Because life is too complicated for CodeWarrior.
--MGL

+++++++++++++++++++++++++++

>From [e-mail] (Timothy Paustian)
Date: Tue, 03 Oct 1995 12:17:27 -0600
Organization: University of Wisconsin - Madison

In article <mouser-0310951107330001@204.191.6.123>, [e-mail]
(Martin-Gilles Lavoie) wrote:
Martin,

> On this note, is there a drag flavor registry??  (why couldn't they use
> AEs for this...)
>

Because not all apps accept AppleEvents. Although I guess you could test a
target app for this, but it could get tricky.

Tim

--
Tim Paustian      "Remember past mistakes, don't fear them"
Department of Bacteriology
University of Wisconsin-Madison
1550 Linden Dr.
Madison, WI 53706      Email:   [e-mail]

---------------------------

>From [e-mail] (John S. Heaney)
Subject: Drag and drop on Finder aliases
Date: 29 Sep 1995 15:45:39 -0700
Organization: CRL Dialup Internet Access        [phone]  [Login: guest]

I'm using System 7.1, but I also noticed this behavior in System 7.0.

If I have an alias to an application, such as Resorcerer, that happens to
be on a separate volume then dragging a file onto the alias does not
work. It works fine if the alias is on the same volume as the
application. It's kind of a pain because I like to have my development
software on one volume and my projects on another. I then put aliases of
various tools in there with my project.

Is there some reason for this behavior and does 7.5 behave this way?

BTW, otherwise the alias works fine. I can double-click to launch the
application.
--
John Heaney              Time flies whether you're having fun or not.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Mon, 2 Oct 1995 23:58:55 GMT
Organization: Will hack for food

John S. Heaney ([e-mail]) wrote:

> Is there some reason for this behavior and does 7.5 behave this way?

This is a desktop database bug and it's in 7.5 also.  I don't do cross
volume aliases much anymore.  At least not if they involve drag and drop.
It's possible to make an alias on the desktop which is on a volume other
than the startup disk by simply making it in a different folder and dragging
it to the desktop.

Jon


---------------------------

>From [e-mail] (David Neves)
Subject: Find vertical extent of call to TextBox?
Date: Fri, 22 Sep 1995 10:42:35 -0500
Organization: The Institute for the Learning Sciences

I would like to know before I make a call to TextBox how much vertical
space the text will take up.  One suggestion I've heard is to make a dummy
call to TextBox and check the pen position as the pen will be positioned
at the end of the text.  Is there something less kludgy?
-Thanks, David

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 25 Sep 1995 15:24:01 GMT
Organization: LMC-IMAG Grenoble France

In article <[e-mail]>, [e-mail]
(David Neves) wrote:

>I would like to know before I make a call to TextBox how much vertical
>space the text will take up.  One suggestion I've heard is to make a dummy
>call to TextBox and check the pen position as the pen will be positioned
>at the end of the text.  Is there something less kludgy?

Hi David,

see the QuickDraw Manager, IM vol.1, p.173.

With GetFontInfo(finfo) proc., you get the _one_ line height
in the current font setting (fheight = finfo.ascent+finfo.descent).
Just compute the number of lines represented by your string
(nlines = (number of CR in string) + 1), and then multiply it by fheight.

HTH
Fr
- -------------------------------------------------------------------------------------
FR Degott ([e-mail])
LogiMath, Lab. LMC-IMAG - Grenoble - France
- -------------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Joey Gray)
Date: Mon, 25 Sep 1995 14:24:08 -0500
Organization: Northwestern University

In article <[e-mail]>, [e-mail]
(David Neves) wrote:

>I would like to know before I make a call to TextBox how much vertical
>space the text will take up.  One suggestion I've heard is to make a dummy
>call to TextBox and check the pen position as the pen will be positioned
>at the end of the text.  Is there something less kludgy?

is the pen position after a call to TextBox documented to be on the bottom
of the last line of text drawn? i don't think it is, and i would actually
be very surprised if it were. given that, i would never rely on the pen
position to accurately reflect the size of the displayed text.

i saw another response to this query that said to use the font information
for the font in use to determine the line height, and then multiply that
by the number of lines in the text - which is determined by the number of
carriage returns in the text. that would work (and be very easy) if your
text already contained all the necessary carriage returns, and each
separate line fit within the rectangle given to TextBox. personally, i
only use TextBox (or something similar) when i have a very long piece of
text that i need wrapped and displayed in a specific rectangle. i'm
assuming that's what you're doing as well.

i can think of two different solutions to this problem:

first, create a text edit record with the text you need to display and an
extremely tall view/destination (i'm not sure which it should be)
rectangle that has the same width as the rectangle you want to display the
text in. after inserting the text into the text edit handle, you can check
the "nLines" field to determine the number of lines your text will become
when wrapped at the specified horizontal length. then multiply that by the
line height for the font that you're using. don't forget to include the
spaces between each line (the "leading" field of a FontInfo record). this,
of course, has the downfall that you have to create a temporary text edit
record.

second, find the source code for NeoTextBox. i think it was featured in a
past develop article, and i know the source code is out there. according
to what i can find on my machine right now, NTB was written by Bryan K.
Ressler. it's basically a replacement for TextBox, and is supposedly quite
a bit faster, and doesn't involve text edit in any way (i think). the
stuff you want from this is the code that determines the line breaks for a
given chunk of text and a fixed horizontal space. the code is very good,
and the copy that i had was pretty well documented.

good luck!

-joey
=====================================================================
Joey Gray                       | [e-mail]
School of Education             | [phone]
Northwestern University         +------------------------------------
**Bandwagon disclaimer:         | "Anybody can cook with gas --
   My opinions are mine, not my |  it takes the French to cook with
   employer's. so there!        |  magnets!" - old newsreel
=====================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Wed, 27 Sep 1995 02:53:07 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

F. Degott ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail]
: (David Neves) wrote:

: >I would like to know before I make a call to TextBox how much vertical
: >space the text will take up.  One suggestion I've heard is to make a dummy
: >call to TextBox and check the pen position as the pen will be positioned
: >at the end of the text.  Is there something less kludgy?

: With GetFontInfo(finfo) proc., you get the _one_ line height
: in the current font setting (fheight = finfo.ascent+finfo.descent).
: Just compute the number of lines represented by your string
: (nlines = (number of CR in string) + 1), and then multiply it by fheight.

You don't know how many lines it is because that's controled by thw width
of the box.  A line of text, regardless of font used, on a screen-wide
window my be less than one line, but TextBox it into a narrower box and
it could end up one word per line, with no CR's in the bunch.
If the purpose of finding out the text overall height, once it's drawn in
a given rectangle, is to adjust the rectangle so that there is a somewhat
even border around it, then the pen position at the end of the string
draw is your stable value from which to determine that.  It's the only
thing that IS at the vertical coordinate you want to know.

Is that the purpose of the datum?  If not, what is it?

I did an aboutBox that was a string TextBox'd into a narrow rect.  It came
out one word per line.  I ran it once, saw that the frame around the rect
needed to come up abot 10 pixels, so I just deducted that from the rect
b,r coord.  But if you want to do it on the fly, that's different.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Harold Ekstrom)
Date: Wed, 27 Sep 1995 11:19:40 -0800
Organization: the ag group, inc.

Here's one way of doing it:

    theTextEditH = TENew( &theTextRect, &theTextRect );
    TESetText( &theString[1], StrLength(theString), theTextEditH );
    theTextHeight = (**theTextEditH).lineHeight * (**theTextEditH).nLines;
    TEDispose( theTextEditH );

Since TextBox draws its text this way, this should calculate the exact
height that TextBox requires. It's not exactly fast though. If you're
worried about speed you could do better by calculating line breaks
yourself using StyledLineBreak.

-harold

- ------------------------------------------------------------
Harold Ekstrom
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Wed, 04 Oct 1995 08:33:26 -0500
Organization: ZERCOM Technologies Inc.

In article <[e-mail]>,
[e-mail] (F. Degott) wrote:

> In article <[e-mail]>, [e-mail]
> (David Neves) wrote:
>
> >I would like to know before I make a call to TextBox how much vertical
> >space the text will take up.  One suggestion I've heard is to make a dummy
> >call to TextBox and check the pen position as the pen will be positioned
> >at the end of the text.  Is there something less kludgy?
>
> Hi David,
>
> see the QuickDraw Manager, IM vol.1, p.173.
>
> With GetFontInfo(finfo) proc., you get the _one_ line height
> in the current font setting (fheight = finfo.ascent+finfo.descent).
> Just compute the number of lines represented by your string
> (nlines = (number of CR in string) + 1), and then multiply it by fheight.
>
> HTH
> Fr
>

NOT.

Actually, it's a little more complicated than that.  You have to take into
account word-wrapping.  If text gets wrapped, you increase the height of
the text to be draw.

David Neves: I dont have the answer to your question, though.  But, make
sure that you wont get word-wrapping before using the fore-mentioned
technique, using GetFontInfo.

Martin-Gilles Lavoie

- -------------------------------------------------------------------
MPW: Because life is too complicated for CodeWarrior.
--MGL

---------------------------

>From [e-mail] (Rene G.A. Ros)
Subject: Gestalt Selectors List 3.1
Date: 2 Oct 1995 19:25:15 +0100
Organization: VU Biology, Amsterdam, The Netherlands


Dear Mac-programmers,


Today I released version 3.1 of the


                       Gestalt Selectors List (GSL)


It lists all sorts of information about the Gestalt Manager, but mainly
about selectors and the meaning of the returned values.
The Gestalt Manager is part of the Apple Macintosh System Software to
enable programmers to determine the availability of certain software and
hardware.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
This release marks the third anniversary of the Gestalt Selectors List.
Many thanks to all the people who provided information: Marco Piovanelli,
John Mancino and Marc Schrier to name a few.
Also, many thanks to Jos van Wezel (Computer Dept., Faculty of Biology,
Vrije Universiteit) for all his help with the mailing list and WWW server!

Please fill in the survey questionnaire included with the GSL 3.1 archive!
WWW Users can also enter a survey form via the GSL Home page at
  http://www.bio.vu.nl/home/rgaros/gestalt/
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

You can obtain the latest version in several ways:
- by sending email to the mail archive server at:
      [e-mail]
  with the subject:
      archive get recent/gestalt-selectors.etx
  or to get the compressed version:
      archive get recent/gestalt-selectors.sit.hqx

- FTP to the info-mac archives at sumex-aim.stanford.edu and get the file
      /info-mac/dev/info/gestalt-selectors-xx.hqx
  You can also use any of its mirror sites.

- World Wide Web
  The GSL is available, behind the editor's home-page, at:
      http://www.bio.vu.nl/home/rgaros/gestalt/
  It is also available, together with other Macintosh FAQs, at:
      http://www.astro.nwu.edu/lentz/mac/faqs/source/gestalt.html
  Also, on the Apple WWW site in:
       http://www.info.apple.com/cgi-bin/lister-pl?Apple.Support.Area/
         Developer_Services/Tool_Chest/OS_Utilities

- America OnLine
  You can find the GSL on AOL in the "MDV/Documents and Proposals" directory.

- AppleLink
  The GSL can be found on AppleLink at this location:

  Developer Support:Developer Services:Tool Chest:OS/Toolbox:

- CompuServe members can find it at the Macintosh Developers Forum
  (GO MACDEV) in the Tools/Debuggers (13) section.
  Or use the Internet locations by using GO INTERNET.

- eWorld
  You can find the GSL on eWorld in this location:

  Apple Developer Services:Tool Chest:OS/Toolbox:

  The shortcut to Apple Developer Services is 'devservice'.

- CD-ROM
  The GSL is included, with permission, on the CD-ROM titles listed below.
  You can find the GSL on the latest release or upcoming release of these
  CD-ROM titles.
      Apprentice CD-ROM                    (Celestin Company)
      BBS in a BOX CD-ROM                  (Arizona Macintosh Users Group)
      Bookmark CD                          (Apple Computer, Inc.)
      CodeWarrior CD                       (MetroWerks Corporation)
      Developer CD Series, Tool Chest      (Apple Computer, Inc.)
      Info-Mac CD-ROM                      (Pacific HiTech, Inc.)
      MacHack CD                           (MacTech Magazine)
      The Right Stuffed CD-ROM             (Quantum Leap Technologies, Inc.)

- Subscribers of the maillist have received their copy already.
  If you want to join this list you need to send a request to:
      [e-mail]
  with in the subject line 'subscribe'. You will then also receive
  several updates before the next version is released. This list is
  only for distribution, not for discussion.

Contributions (new info, remarks, etc.) for the list can be send to:
      [e-mail]

Please, be aware that it may take a couple of days before the new version
is available at all these locations. It is available immediatly by using
the mail archive server.

Beside a large number of new and changed selectors, these are the major
changes since the previous version:

***************************************************************************
Paul Cunningham (Teknosys, Inc.) mentioned a number of problems with some
Third Party selectors.

Nobu Toge found that IM OS Utilities contains an error regarding the
selector function. This was confirmed by Steve Ko (from Apple).

Anonymous contributors provided information about the PB 190 and PB 5300
as well as System Update 2.0 Seed 6.

Includes information from the August Developer CD and of the ETO 18
Gestalt header file.
Also info from the Developer Notes regarding the PB190, PB2300, PB5300 and
PB500 PPC Upgrade Card.

And lots more:

Added selectors
    Apple System  : ag_v, pccd, pwky
    Apple Add.    : mtlk
    Third Parties : Kals, SCom, SKey
Added unknown
    Apple Softw.  : ATI , blck, hrad, irhk, pclk, puir, pwtr, SNKR, srad,
                    sysu, valk
    Third Parties : Aarn, Aarp, Aaru, Copl, HPKb, LLSM, TRSN, VrkG, VrkS,
                    VrkU
Changed selectors
    Apple System  : aslm, cput, fnd , fnd^, mach, powr, sdev, snhw, te  ,
                    teat, tsma, tsmv, via1, via2
    Apple Add.    : tmTV
    Third Parties : -
Changed unknown
    Apple Softw.  : EM20, fndx, pxtn, serh
    Third Parties : -
Previously unknown
    Apple System  : -
    Apple Add.    : q3vr
    Third Parties : CHSR
Includes updates 3.0.1 up to and including 3.0.7, sent to subscribers of
the mailing list.

***************************************************************************


Best regards,
Rene Ros
[e-mail]



--
  Rene G.A. Ros                                               [e-mail]
  Amsterdam, The Netherlands                 http://www.bio.vu.nl/home/rgaros/
- ------------------------------------------------------------------------------
  HOMO SAPIENS NON URINAT IN VENTUM

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 03 Oct 1995 14:18:14 -0700
Organization: Internet for the Olympic Peninsula

In article <44paqb$[e-mail]>, [e-mail] (Rene G.A.
Ros) wrote:

> Today I released version 3.1 of the
>
>
>                        Gestalt Selectors List (GSL)


This labor of love by Rene' is an essential part of one's collection of
tools, IMHO.  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Go, Ms!
   [e-mail]

---------------------------

>From [e-mail] (ddenson)
Subject: Help with UniversalProcPtrs
Date: 4 Oct 1995 16:42:10 -0400
Organization: NandO.net

I am using Think C++ 7.0.4 (Upgraded over the course of a couple years from
6.0), and have run into a problem with UPPs.

Being interested in doing a project using the QuickTime Music
Architecture, I tried compiling some projects I found on the develop 22 CD,
and it would seem that I am missing some files involving UniversalProcPtr:


Am I missing something?  A search of the standard include files with
Symantec's distribution never mentions this beast.  However, all the
Quicktime headers on the CD reference it.  What else do I need?

Please note that I am a relative newbie to this kind o' thing.  I
understand what a UPP is (I still have a 68K Mac, however), but can't find
that one last include file...

Thanks,
Dave




+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Thu, 05 Oct 1995 01:56:04 -0700
Organization: Best Internet Communications

In article <44urj2$[e-mail]>, [e-mail] (ddenson) wrote:
>Being interested in doing a project using the QuickTime Music
>Architecture, I tried compiling some projects I found on the develop 22 CD,
>and it would seem that I am missing some files involving UniversalProcPtr:
>
>Am I missing something?  A search of the standard include files with
>Symantec's distribution never mentions this beast.  However, all the
>Quicktime headers on the CD reference it.  What else do I need?

The Universal Interfaces is a complete set of Mac headers which is
UPP-aware (among other changes). It may or may not have come with your
Symantec C. If not, they're available at:

<ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Tool_Chest/Inter
faces/Universal_Interfaces.sit.hqx>

Enjoy,
 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence Kearney)
Date: Thu, 05 Oct 1995 20:53:42 -0700
Organization: Applied Signal Technology

In article <44urj2$[e-mail]>, [e-mail] (ddenson) wrote:

> Being interested in doing a project using the QuickTime Music
> Architecture, I tried compiling some projects I found on the develop 22 CD,
> and it would seem that I am missing some files involving UniversalProcPtr:
>
> Am I missing something?  A search of the standard include files with
> Symantec's distribution never mentions this beast.  However, all the
> Quicktime headers on the CD reference it.  What else do I need?
>
> Dave

In the Think C++ folder, you should find one titled "Mac #includes". In this
folder should be another titled "Universal Headers". The definition you
are looking for is defined in either "Types.h" or "MixedMode.h".

You usually should have to explicitly define this as these files are
defined in the Think C pre-compiled header list (unless you're not using
this or you've redefined it).

--
Larry Kearney                   |   "You want fries with that?"
Applied Signal Technology       |
[e-mail]        |

---------------------------

>From [e-mail] (Yicheng An)
Subject: How to detect if the cap-lock is on?
Date: 3 Oct 1995 13:31:01 +0100
Organization: Dept. of Informatics, University of Oslo, Norway


Hi,

I wonder how to detect if the cap-lock is on? anyway?

Thanks,

Yicheng


+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Tue, 3 Oct 1995 21:42:16 GMT
Organization: Will hack for food

Yicheng An ([e-mail]) wrote:

> I wonder how to detect if the cap-lock is on? anyway?

Use GetKeys.

Jon



+++++++++++++++++++++++++++

>From [e-mail] (Chris Rudolph)
Date: Tue, 03 Oct 1995 15:38:15 -0800
Organization: Motion Works Group Limited

In article <[e-mail]>, [e-mail] (Jon Pugh) wrote:

> Yicheng An ([e-mail]) wrote:
>
> > I wonder how to detect if the cap-lock is on? anyway?
>
> Use GetKeys.
>
> Jon

Why not just look at your keyboard and see if the cap lock is green.

GRIN...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Rudolph
Senior Software Engineer, Technology Works.
Motion Works Group Limited

130 - 1020 Mainland St, Vancouver, B.C., Canada.  V6B 2T4
Telephone:    [phone].
Fax:             604-685-6105.

Internet:  [e-mail]
AppleLink: D2276 ( Subject: Attn: Chris Rudolph )
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

+++++++++++++++++++++++++++

>From [e-mail] (Dennis Chronopoulos)
Date: Wed, 04 Oct 1995 07:55:58 +0300
Organization: Student

In article <44rae5$[e-mail]>, [e-mail] (Yicheng An) wrote:

> I wonder how to detect if the cap-lock is on? anyway?

You can use the following Pascal function to determine if the Caps-Lock
key is on or off.


 Function CapsLockIsOn: boolean;
  Const
   CapsKeysCode = 57;
  Var
   kbState: KeyMap;
 Begin
  GetKeys(kbState);
  CapsLockIsOn := kbState[CapsKeysCode];
 End;


I hope that this helps you.

Dennis

_______________
[e-mail]
Dennis Chronopoulos
Kifissia, Athens, Greece

+++++++++++++++++++++++++++

>From [e-mail] (Carl Gustafson)
Date: 4 Oct 1995 12:21:04 GMT
Organization: Imaging and Computer Vision Center, Drexel University

In article <44rae5$[e-mail]>, [e-mail] (Yicheng An) wrote:

> Hi,
>
> I wonder how to detect if the cap-lock is on? anyway?
>
> Thanks,
>
> Yicheng

boolean CapsLockDown (void)
{
      KeyMap   theKeys;

   GetKeys (&theKeys);
   return BitTst (&theKeys,62);  // 62 is offset for caps lock key in KeyMap
}

--
Carl Gustafson
Imaging and Computer Vision Center
Drexel University, Philadelphia, Penna
- ----------------------------------------------------------
I don't speak for Drexel, and Drexel doesn't listen to me...

+++++++++++++++++++++++++++

>From [e-mail] (Thomas Reed)
Date: Thu, 05 Oct 1995 09:05:53 -0500
Organization: Washington University

In article <44rae5$[e-mail]>, [e-mail] (Yicheng An) wrote:

>I wonder how to detect if the cap-lock is on? anyway?

There are a couple ways.  One is to use GetKeys, but I've found that's
more trouble than it's worth.  Another way to do it is to use EventAvail
to get a pending nullEvent and examine the event.modifiers field.  Since
there are always nullEvents bouncing around the system, and EventAvail
doesn't remove the event from the queue, this works quite well for me...

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]               Medical School
[e-mail]            Saint Louis, MO
http://medinfo.wustl.edu/~reed
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

---------------------------

>From [e-mail] (Ben Hellstrom)
Subject: How to tell if a volume is busy ?
Date: Sat, 07 Oct 1995 05:30:53 -0400
Organization: jaguNET Access Services

Howdy.

I need a hint.  How does one tell whether a mounted volume is busy?
Obviously I could Eject it and see if I get a fBsyErr, but if there are no
files busy this has the unfortunate side-effect of ejecting the volume.

I traversed the VCB buffer and pulled the vcbAtrb of the affected volume
but it seems to be bogus.  According to IM "Files" 2-79, bit 6 of vcbAtrb
should be set if the volume is busy.  The only problem is that vcbAtrb
seems to always be 0x0000 regardless of whether I have files open on the
volume or not.

TIA.

--
Ben Hellstrom
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Sat, 07 Oct 1995 08:21:27 -0700
Organization: MindVision Software

In article <[e-mail]>,
[e-mail] (Ben Hellstrom) wrote:

> Howdy.
>
> I need a hint.  How does one tell whether a mounted volume is busy?
> Obviously I could Eject it and see if I get a fBsyErr, but if there are no
> files busy this has the unfortunate side-effect of ejecting the volume.
>
> I traversed the VCB buffer and pulled the vcbAtrb of the affected volume
> but it seems to be bogus.  According to IM "Files" 2-79, bit 6 of vcbAtrb
> should be set if the volume is busy.  The only problem is that vcbAtrb
> seems to always be 0x0000 regardless of whether I have files open on the
> volume or not.

I believe the busy bit in vcbAtrb is only valid for MFS volumes. What are
you trying to accomplish here? Any mounted HFS disk should have open files
(Desktop, etc).

Steve Kiene
MindVision Software
File System Nerd

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 7 Oct 1995 14:01:45 -0400
Organization: America Online, Inc. (1-800-827-6364)

Ben Hellstrom wrote:
>I need a hint.  How does one tell whether a mounted volume is
>busy?  Obviously I could Eject it and see if I get a fBsyErr,
>but if there are no files busy this has the unfortunate
>side-effect of ejecting the volume.

Ben, what are you trying to accomplish?

If you're just trying to find out if the volume can be unmounted, then
that's not really possible. You might think you could check for open
files, but there are files opened on a volume (for example: the catalog
and extents overflow files opened by the HFS file system, the Desktop
Manager files, the AppleShare PDS file) that are automatically closed by
the system when a volume is unmounted. You really just have to try Unmount
and see if you get a fBsyErr error back.

If you're trying to accomplish something else, let us know.

- Jim Luther

---------------------------

>From .nerd. <[e-mail]>
Subject: Killed By Update Events (again)
Date: 3 Oct 1995 03:29:45 GMT
Organization: UCD

Okay, so I am a new mac programmer, so flame me now.  I am writing a
small app with just one window and for some reason it gets update events
constantly; I mean I have yet to receive one null event.  As far as my
understanding goes, an update event is sent to an app if one of its
windows has a nonempty update region.  Is having another window drawn
over the contents of the window in question the only thing that will put
something in the updateRgn?

Thanks for your help.
Adam Marks

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence Kearney)
Date: Wed, 04 Oct 1995 03:40:20 -0700
Organization: Applied Signal Technology

In article <44qan9$[e-mail]>, .nerd. <[e-mail]> wrote:

> Okay, so I am a new mac programmer, so flame me now.  I am writing a
> small app with just one window and for some reason it gets update events
> constantly; I mean I have yet to receive one null event.  As far as my
> understanding goes, an update event is sent to an app if one of its
> windows has a nonempty update region.  Is having another window drawn
> over the contents of the window in question the only thing that will put
> something in the updateRgn?
>
> Thanks for your help.
> Adam Marks

You need to make sure that you have called BeginUpdate(...) and
EndUpdate(...) before and after your call to your updating code. These
calls are the only way the system has of knowing you have handled the
update event. Until this is done, it will continue to send you the update
events.


   switch ( eventType )
   {
      case updateEvt:
         BeginUpdate( (WindowPtr)event->message );
            MyHandleUpdateEvent( ... );
         EndUpdate( (WindowPtr)event->message );
         break;

      ...
   }

--
Larry Kearney                   |   "You want fries with that?"
Applied Signal Technology       |
[e-mail]        |

+++++++++++++++++++++++++++

>From [e-mail] (Frank Durgin, et al.)
Date: Tue, 03 Oct 1995 14:34:49 -0400
Organization: Swarthmore Visual Perception Lab

In article <44qan9$[e-mail]>, .nerd. <[e-mail]> wrote:

> Okay, so I am a new mac programmer, so flame me now.  I am writing a
> small app with just one window and for some reason it gets update events
> constantly; I mean I have yet to receive one null event.  As far as my
> understanding goes, an update event is sent to an app if one of its
> windows has a nonempty update region.  Is having another window drawn
> over the contents of the window in question the only thing that will put
> something in the updateRgn?


Do you do anything with the update event? If you keep ignoring it, the OS
will keep sending it to you.

Ta,
        -Stephen

--
Frank Durgin & various student (and recent alumna/us) researchers
- --------------------------
Visual Perception Laboratory
Department of Psychology
Swarthmore College

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 4 Oct 1995 11:49:02 GMT
Organization: University of Pennsylvania

In article <44qan9$[e-mail]>, .nerd.  <[e-mail]> wrote:
>Okay, so I am a new mac programmer, so flame me now.  I am writing a
>small app with just one window and for some reason it gets update events
>constantly; I mean I have yet to receive one null event.  As far as my
>understanding goes, an update event is sent to an app if one of its
>windows has a nonempty update region.  Is having another window drawn
>over the contents of the window in question the only thing that will put
>something in the updateRgn?

When you get your updateEvt, do you call beginUpdate, then do your drawing,
and then call endUpdate?  This is the right way to handle an UpdateEvt.
BeginUpdate sets the clipping region for the window so that you only draw
the parts that have been invalidated; EndUpdate zeroes out the updateRgn so
that you don't get the same UpdateEvt next time around.

If you _don't_ call BeginUpdate/EndUpdate, your updateRgn will never be
zeroed out, and you will keep getting UpdateEvts instead of null events.

One other point: you ask if the updateRgn is only added to in response to a
window being drawn on top of the window.  No; there's at least two other
times that come to mind.  One is when you first make your window visible;
the entire content area will be invalid.

The second is when you call InvalRect or InvalRgn on some part of your
window yourself.  Well-structured Mac programs do lots and lots of this;
except for unusual cases (e.g. repeatedly drawing the outline of an object
the user's dragging), you can do _all_ of your drawing in response to
updateEvts.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----    this account.  It's also available through
  _| ,| ,|    [_]     my homepage:
   |  |  |    [_]     http://babel.ling.upenn.edu/~kurisuto/homepage.html




+++++++++++++++++++++++++++

>From [e-mail] (Thomas Reed)
Date: Wed, 04 Oct 1995 15:19:20 -0500
Organization: Washington University

In article <44qan9$[e-mail]>, .nerd. <[e-mail]> wrote:

>Okay, so I am a new mac programmer, so flame me now.  I am writing a
>small app with just one window and for some reason it gets update events
>constantly;

Probably, when you handle the update event, you are not calling
BeginUpdate or EndUpdate.  You must bracket your update-handling code with
a call to these routines, or the event will just swing around again and
hit you in the face.

E.g.:

BeginUpdate(someWindow);
// do your update stuff here
EndUpdate(someWindow);

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]               Medical School
[e-mail]            Saint Louis, MO
http://medinfo.wustl.edu/~reed
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 4 Oct 1995 15:42:50 GMT
Organization: National Renewable Energy Laboratory

In article <44qan9$[e-mail]> .nerd., [e-mail]
writes:

>Is having another window drawn
>over the contents of the window in question the only thing that will put
>something in the updateRgn?

This is the short list of things that a window's updateRgn non-empty,
i.e. generate update events:

1)  Another window in front of the window in question that is moved or
closed, causing some portion of your window to need redrawing.

2)  Creating the window.

3)  Calling InvalRgn() or InvalRect() to force some portion of the
window to be invalid.

---------------------------

>From [e-mail] (Greg Simon)
Subject: Making TextEdit field a one-liner
Date: 28 Sep 1995 22:47:31 GMT
Organization: Penn State University


I have created a dialog box (using ResEdit) with some TextEdit fields. I
want to restrict these fields to a single line, and have the carrage
return apply to the 'OK' button on my dialog box (with the thick outline).
Instread, the default is multiple-line textedit fields and the OK button
(which is #1) is not double-outlined.

How do I do this?

--
Greg Simon <[e-mail]>
Electrical Engineering Graduate Student
Newton Developer
Penn State University

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Fri, 29 Sep 1995 12:54:51 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>, [e-mail]
(Greg Simon) wrote:
>
>
> I have created a dialog box (using ResEdit) with some TextEdit fields. I
> want to restrict these fields to a single line, and have the carrage
> return apply to the 'OK' button on my dialog box (with the thick outline).
> Instread, the default is multiple-line textedit fields and the OK button
> (which is #1) is not double-outlined.
>
> How do I do this?
>

Define a filter proc for ModalDialog that checks for keyDown events.  If
the
character is the return or enter key, return true from the filter proc
after setting the item hit to the appropriate value (1 for the default
button).  Any other characters you don't want, ignore.  Note that you
may want to handle command-keys as well such as cut, copy, paste - if
these come through you can call DlgCut, DlgCopy, etc.

Here's an example - first part is the filter proc, rest is code called
by it.

Dave Stone


pascal Boolean CheckEditDlgFilter(DialogPtr theDlg,EventRecord
*theEvent,short *itemHit)
{
Boolean isHandled;

        isHandled = CheckForEditItem(theDlg,theEvent);

        if(!isHandled) {                                                //      Check for CR or ETX
                isHandled = CheckForEnterKey(theDlg,theEvent);
                if(isHandled == TRUE)                                   //      True - set itemHit to default
                                *itemHit = 1;
        }

        if(!isHandled) {                                                //      Check for cancel event (cmd-period, esc, etc.)
                isHandled = CheckForCancel(theDlg,theEvent);
                if(isHandled == TRUE)                                   //      True - assume 2 = cancel button
                                *itemHit = 2;
        }

        return(isHandled);
}


Boolean CheckForEditItem(DialogPtr theDlg,EventRecord *theEvent)
{
Boolean isHandled;
char    ch;

        isHandled = FALSE;

        if(theEvent->what == keyDown || theEvent->what == autoKey) {
                if(theEvent->modifiers & cmdKey) {
                        ch = (theEvent->message & charCodeMask);
                        isHandled = TRUE;
                        if(ch == 'c' || ch == 'C') DlgCopy(theDlg);
                        else if(ch == 'x' || ch == 'X') DlgCut(theDlg);
                        else if(ch == 'v' || ch == 'V') DlgPaste(theDlg);
                        else if(ch == 'b' || ch == 'B' || ch == 0x08) DlgDelete(theDlg);
                        else if(ch == 'a' || ch == 'A') DlgSelect(theDlg);
                        else isHandled = FALSE;
                }
        }
        return (isHandled);
}

short DlgSelect(DialogPtr theDlg)
{
DialogPeek      dp;
short           di;

        dp = (DialogPeek)theDlg;

        if(dp->editField > 0) {
                TESetSelect(0,32767,dp->textH);
                di = dp->editField + 1;
        } else di = 0;

        return (di);
}

+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Sun, 01 Oct 1995 14:16:52 -0400
Organization: Communications Accessibles Montreal, Quebec Canada

In article <[e-mail]>, [e-mail]
(Greg Simon) wrote:

> I have created a dialog box (using ResEdit) with some TextEdit fields. I
> want to restrict these fields to a single line, and have the carrage
> return apply to the 'OK' button on my dialog box (with the thick outline).
> Instread, the default is multiple-line textedit fields and the OK button
> (which is #1) is not double-outlined.

If you are using a modal dialogue and System 7, then you can simply use
the SetDialogDefaultItem () function.  It will draw the thick border
around the button and make the return and enter keys apply to the OK
button.  Add this line somewhere after you create the dialogue:

SetDialogDefaultItem (dialog, ok);

Also, there exists SetDialogCancelItem () and SetDialogTracksCursor () to
handle the cancel button and change the cursor to an i-beam.

Hope that helps...


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  H H      |                   |                                       |
  | |      | Sean McBride      |                                       |
H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
  | |      | Montreal, Canada  |                                       |
  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---------------------------

>From [e-mail] (Mark Kadonoff)
Subject: MixedMode Manager Routine Descriptors for SetDialogItem calls?
Date: Tue, 03 Oct 1995 14:33:53 -0500
Organization: Reprographic Products Group

I'm updating a Photoshop plug-in from 68K to PowerMac, and having
difficulties with procPtrs in my SetDialogItem calls. These procPtrs are
coerced as handles, and I'm unsure whether they need to be set up as
Routine Descriptors.

Thanks,

Mark Kadonoff

+++++++++++++++++++++++++++

>From [e-mail] (Erichsen)
Date: Tue, 03 Oct 1995 18:13:22 -0700
Organization: Disorganized

In article <[e-mail]>, [e-mail] (Mark
Kadonoff) wrote:

>I'm updating a Photoshop plug-in from 68K to PowerMac, and having
>difficulties with procPtrs in my SetDialogItem calls. These procPtrs are
>coerced as handles, and I'm unsure whether they need to be set up as
>Routine Descriptors.

They do need to be routine descriptors. There's a macro that'll do it for you:

UserItemUPP     ItemUPP;

ItemUPP = NewUserItemProc( UserItemProc );

Then just call SetDialogItem like this:

SetDialogItem( dialog, item, itemType, ( Handle ) ItemUPP, &itemRect );

+++++++++++++++++++++++++++

>From [e-mail] (Vance Huntley)
Date: Wed, 04 Oct 1995 09:08:01 -0400
Organization: WebGenesis

In article <[e-mail]>, [e-mail] (Mark
Kadonoff) wrote:

> I'm updating a Photoshop plug-in from 68K to PowerMac, and having
> difficulties with procPtrs in my SetDialogItem calls. These procPtrs are
> coerced as handles, and I'm unsure whether they need to be set up as
> Routine Descriptors.
>
> Thanks,
>
> Mark Kadonoff

Yes, they need to be routine descriptors.  Here is an example of the
method which I have been using which should work in both 68K & PPC:


in the prototypes section:

pascal void DrawColorSample(DialogPtr theDialog, short item);

#if USESROUTINEDESCRIPTORS
   RoutineDescriptor gDrawColorSampleRD =
         BUILD_ROUTINE_DESCRIPTOR(uppUserItemProcInfo, DrawColorSample);
#endif



In the Dialog-handling function

   DialogPtr      theDialog = GetNewDialog(kColorsDLOG,0,(WindowPtr) -1);

   // set drawing procedure for the user item
   GetDialogItem( theDialog, iSample, &itemType, &itemHandle, &itemRect );
#if USESROUTINEDESCRIPTORS
      SetDialogItem( theDialog, iSample, itemType,
(Handle)&gDrawColorSampleRD, &itemRect );
#else
      SetDialogItem( theDialog, iSample, itemType, (Handle)
DrawColorSample, &itemRect );
#endif


Sort of messy with all those #if's but it works


Vance

--
Vance Huntley

Software Development & Technical Support
WebGenesis, Inc.
Ithaca, NY

607.255.1396
- -----------
Check out our site, "The Globe"!
<http://www.webgenesis.com>

---------------------------

>From [e-mail] (MarkWomack)
Subject: Photoshop Filter Host?
Date: 28 Sep 1995 19:44:22 -0400
Organization: America Online, Inc. (1-800-827-6364)

Does anyone have any examples of being a Photoshop filter host?  The docs
I have are on creating a filter.  I want information about the other end.

Thanks!
Mark

+++++++++++++++++++++++++++

>From [e-mail] (Joe Zobkiw)
Date: Thu, 28 Sep 1995 22:27:37 -0400
Organization: TripleSoft Inc.

In article <44fc0m$[e-mail]>, [e-mail]
(MarkWomack) wrote:

>Does anyone have any examples of being a Photoshop filter host?  The docs
>I have are on creating a filter.  I want information about the other end.

I don't think there is any documentation on that. You have to figure it
out yourself from the Photoshop SDK.

Joe Zobkiw
President

- ----------------------------------------------------------------
TripleSoft Inc, Macintosh Software Development     CIS: 74631,1700
P.O. Box 30774, Raleigh, NC 27622-0774      AOL/eWorld: TripleSoft
voice/fax [phone]                Internet: [e-mail]
- ----------------------------------------------------------------
 Look for "A Fragment of Your Imagination" from Addison-Wesley...
PowerPC/Code Resources/Fragments/Components/Extensions/and more...

+++++++++++++++++++++++++++

>From [e-mail] (Bas A. Schulte)
Date: Fri, 29 Sep 1995 10:01:24 +0100
Organization: Models, Inc.

In article <44fc0m$[e-mail]>, [e-mail]
(MarkWomack) wrote:

> Does anyone have any examples of being a Photoshop filter host?  The docs
> I have are on creating a filter.  I want information about the other end.
>
> Thanks!
> Mark

Mark,

the only sample I've seen in source-code is NIH Image. It's available
somewhere at one of the NASA archives, I think.

BTW, I did this (being an acquire plug-in host), and it's tricky, but it
can be done. I used only the Adobe plug-in documentation.

Good luck.

+++++++++++++++++++++++++++

>From [e-mail] (Carl Gustafson)
Date: 2 Oct 1995 14:02:49 GMT
Organization: Imaging and Computer Vision Center, Drexel University

In article <[e-mail]>,
[e-mail] (Bas A. Schulte) wrote:

> the only sample I've seen in source-code is NIH Image. It's available
> somewhere at one of the NASA archives, I think.

The NIH-Image source code's home is (and can be ftp'd from:

   zippy.nimh.nih.gov

It is built using Metrowerks Pascal.

--
Carl Gustafson
Imaging and Computer Vision Center
Drexel University, Philadelphia, Penna
- ----------------------------------------------------------
I don't speak for Drexel, and Drexel doesn't listen to me...

---------------------------

>From [e-mail] (Byron Han)
Subject: PowerPC handling of preloaded CODE resources?
Date: 29 Sep 1995 14:26:23 -1000
Organization: LavaNet, Inc.

If I have a fat binary and the CODE resources are marked preload, locked,
what happens on a PowerpC machine?  Do I need to manually
go through and unlock and purge/release all of these resources?
--
Byron Han, Chief Engineer * Han Chen & Son * PO Box 61557 * Honolulu HI 96839
email: [e-mail]        web: http://www.hanchenson.com/~han/han.html
ISP: LavaNet, Honolulu HI

+++++++++++++++++++++++++++

>From [e-mail] (Joe Zobkiw)
Date: Sat, 30 Sep 1995 00:04:39 -0400
Organization: TripleSoft Inc.

In article <44i2rf$[e-mail]>, [e-mail] (Byron Han) wrote:

>If I have a fat binary and the CODE resources are marked preload, locked,
>what happens on a PowerpC machine?  Do I need to manually
>go through and unlock and purge/release all of these resources?

Once would think that the resources would get loaded just as any other,
low in the heap, when the resource fork is opened. You can do a quick
check of this by dropping into MacsBug and dumping the contents of the
heap. You will probably see the CODE resources sitting there, locked.

Joe Zobkiw
President

- ----------------------------------------------------------------
TripleSoft Inc, Macintosh Software Development     CIS: 74631,1700
P.O. Box 30774, Raleigh, NC 27622-0774      AOL/eWorld: TripleSoft
voice/fax [phone]                Internet: [e-mail]
- ----------------------------------------------------------------
 Look for "A Fragment of Your Imagination" from Addison-Wesley...
PowerPC/Code Resources/Fragments/Components/Extensions/and more...

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 30 Sep 1995 05:07:57 GMT
Organization: Primenet [phone]

Joe Zobkiw ([e-mail]) wrote:
: In article <44i2rf$[e-mail]>, [e-mail] (Byron Han) wrote:

: >If I have a fat binary and the CODE resources are marked preload, locked,
: >what happens on a PowerpC machine?  Do I need to manually
: >go through and unlock and purge/release all of these resources?

: Once would think that the resources would get loaded just as any other,
: low in the heap, when the resource fork is opened. You can do a quick
: check of this by dropping into MacsBug and dumping the contents of the
: heap. You will probably see the CODE resources sitting there, locked.

And Heaven help you if you jump directly to it from native code....
: ------------------------------------------------------------------
: TripleSoft Inc, Macintosh Software Development     CIS: 74631,1700
: P.O. Box 30774, Raleigh, NC 27622-0774      AOL/eWorld: TripleSoft
: voice/fax [phone]                Internet: [e-mail]
: ------------------------------------------------------------------
:  Look for "A Fragment of Your Imagination" from Addison-Wesley...
: PowerPC/Code Resources/Fragments/Components/Extensions/and more...

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Mon, 2 Oct 95 00:26:59 +0100
Organization: Network Analysis Ltd


In article <44i2rf$[e-mail]> (comp.sys.mac.programmer.misc),
[e-mail] (Byron Han) writes:

> If I have a fat binary and the CODE resources are marked preload, locked,
> what happens on a PowerpC machine?

Well, they get preloaded and locked just like any other resource.
At the risk of teaching grandmothers how to suck eggs, typing
"rd -t 'CODE'" to Macsbug would have told you that...

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!eu.britain.net!nan!sw         AppleLink: NAN.LTD
Phone: [phone]                    Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Sun, 01 Oct 1995 23:21:10 -0400
Organization: Tulip Software

In article <44i2rf$[e-mail]>, [e-mail] (Byron Han) wrote:

> If I have a fat binary and the CODE resources are marked preload, locked,
> what happens on a PowerpC machine?  Do I need to manually
> go through and unlock and purge/release all of these resources?

Yes, this is typical of CodeWarrior generated apps. Is that what you're using?

You correctly surmised that the CODE resources will be unnecessarily
loaded when launching on a PowerPC machine.

Although Metrowerks recommends against it, my solution is to simply remove
the pre-load flag from the CODE resources. It works fine for me. Your
mileage may vary. The recommended approach is (as you guessed) to go
through and release all those loaded resources once the PowerPC code
begins execution. YUCK!

IHTH

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Greg Branche)
Date: Mon, 02 Oct 1995 11:50:48 -0700
Organization: General Magic

In article <[e-mail]>, [e-mail] (Ed
Anson) wrote:

>In article <44i2rf$[e-mail]>, [e-mail] (Byron Han) wrote:
>
>> If I have a fat binary and the CODE resources are marked preload, locked,
>> what happens on a PowerpC machine?  Do I need to manually
>> go through and unlock and purge/release all of these resources?
>
>[snip]
>Although Metrowerks recommends against it, my solution is to simply remove
>the pre-load flag from the CODE resources. It works fine for me. Your
>mileage may vary. The recommended approach is (as you guessed) to go
>through and release all those loaded resources once the PowerPC code
>begins execution. YUCK!
>

Unlocking and releasing all of the pre-loaded CODE resources
after-the-fact may leave gaping holes low in the heap, with locked,
immoveable resources above the holes, thereby fragmenting the heap.

The solution that I used for the MPW shell was to leave all CODE resources
non-preload, and have code run during initialization which manually
pre-loaded those CODE resources which were historically marked preload in
pre-3.4 shells.  By doing it yourself, you can also ensure that the heap
is properly initialized prior to sucking in all of the additional CODE
resources.  (Of course, you have to ensure that all of the initialization
code for this resides in the "Main" segment, so that no segments are
loaded dynamically.)

Greg Branche
Magic Cap Entomologist
General Magic, Inc.

---------------------------

>From [e-mail] (Dave Smith)
Subject: Printing a Hairline?
Date: Fri, 29 Sep 1995 09:20:16 -0500
Organization: Westhead Consulting

How do I go about drawing a line that is thinner than 1 pixel (1/72 of a
inch) to the printer? Ideally this would be done in code.

--
Dave Smith                     |    "If the women don't find
Westhead Consulting            |    you handsome, they should
Etobicoke, Ontario             |     at least find you handy"
CANADA M8W 4S3                 |         - Red Green
[phone]                 |

+++++++++++++++++++++++++++

>From [e-mail] (Ronald Ek)
Date: 29 Sep 1995 16:10:43 GMT
Organization: SoftDesign

Hi,

You have to use PicComments for this. You use SetLineWidth(Point aPt)
to define the thickness of the line. It is doucumented in a technical
note from Apple.

I can send you some code for it if you want.

CU
Ronald

+++++++++++++++++++++++++++

>From [e-mail] (Patrik Johansson)
Date: Sat, 30 Sep 1995 20:19:32 +0100
Organization: KTH

In article <[e-mail]>,
[e-mail] (Dave Smith) wrote:

> How do I go about drawing a line that is thinner than 1 pixel (1/72 of a
> inch) to the printer? Ideally this would be done in code.

Well, PicComments will probably do it for you!

Pj

- ------------------------------------------------------------
Patrik Johansson
Royal Institute of Technology, Sweden
[e-mail]
- ------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (John Young)
Date: 1 Oct 1995 04:40:53 GMT
Organization: Southeast Network Services, Inc.

In article <[e-mail]>,
[e-mail] (Dave Smith) wrote:

> How do I go about drawing a line that is thinner than 1 pixel (1/72 of a
> inch) to the printer? Ideally this would be done in code.

The PicComments solution, I believe, will only work on a PostScript printer.
You could try increasing the resolution of the printer to 300x300 and scaling
everything else larger except for your hairline.

It used to be PrGeneral to get and set the resolution of the printer.
I haven't had a need to do that for some time, and I don't know if there
has been a change.


See ya,
John

+++++++++++++++++++++++++++

>From [e-mail] (Milton Aupperle)
Date: Sat, 30 Sep 1995 16:02:07 -0700
Organization: CADVision

> In article <[e-mail]>,
> [e-mail] (Dave Smith) wrote:
>
> > How do I go about drawing a line that is thinner than 1 pixel (1/72 of a
> > inch) to the printer? Ideally this would be done in code.

There are really 2 ways of doing it, either draw the image at the
printer's maximum printing resolution and setting up the PREC for the
printer at say 300 , 360 or 600 dpi or use the pict/postscript command to
do fractional widths. Note that the pictscript command does work with some
non - postscript printers (most 3rd part inkjets . laser writers) but not
all of them and there is no way of telling if they actually will support
it (it's up to the printer driver to do it). I find Apple flip flops on
this a lot and some versions of their non poscript printer drivers will
and other won't.

The postscript/pict command for fractional line weights and text rotation
can also be embedded in Pict files for import into other applications
(like macdraw, canvas etc.) too, which is sort of a bonus.

milton

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Sun, 01 Oct 1995 23:11:39 -0500
Organization: Huh? What's that?

In article <[e-mail]>,
[e-mail] (John Young) wrote:

> In article <[e-mail]>,
> [e-mail] (Dave Smith) wrote:
>
> > How do I go about drawing a line that is thinner than 1 pixel (1/72 of a
> > inch) to the printer? Ideally this would be done in code.

The technique is described in IM Imaging with QuickDraw, pages B-35 to
B-37. It's a little complicated and a little strange, but it does work as
advertised.


> The PicComments solution, I believe, will only work on a PostScript printer.
> You could try increasing the resolution of the printer to 300x300 and scaling
> everything else larger except for your hairline.

Not entirely correct. Quoting from page B-36, "The SetLineWidth picture
comment is implemented by all PostScript LaserWriter printer drivers and
by some QuickDraw printer drivers." The text goes on to describe how the
QuickDraw LaserWriter SC driver implements the comment in its own unique
fashion, but makes no reference to the ImageWriter driver.

-es

__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

To send or not to send that is the question. Whether it is nobler to risk
the flames and arrows of outraged readers, or lurk in silence and never
post inappropriately.
   -Beth Frank

---------------------------

>From [e-mail] (Adam Lloyd)
Subject: [FAQ?] Saving GWorld to PICT...
Date: Thu, 28 Sep 1995 19:35:36 +0000
Organization: a sluggish molehill.

I'm sure I've read about this in here before, but going back through my
archives and various technical references I've been unable to find any info
on how do to it.

So, is it possible to save a GWorld as a PICT file? And if so, could anyone
give me any pointers to where I can find information on this?

Thanks,
Adam.

--
Adam Lloyd
  SlideMan Project
  (WordSlide Maker).



+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Fri, 29 Sep 1995 02:33:23 -0700
Organization: Best Internet Communications

In article <[e-mail]>, [e-mail]
(Adam Lloyd) wrote:

>I'm sure I've read about this in here before, but going back through my
>archives and various technical references I've been unable to find any info
>on how do to it.
>
>So, is it possible to save a GWorld as a PICT file? And if so, could anyone
>give me any pointers to where I can find information on this?

SetGWorld() to the GWorld.
Open a picture.
Use CopyBits to copy the picture data on top of itself.
Close the picture.
SetGWorld() back.

No bits were harmed in the making of this picture.

 - Tim

I've got to start saving these responses.

--
Tim Dierks
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (PANG HEE KIANG)
Date: 30 Sep 1995 02:15:01 GMT
Organization: National University of Singapore


:1) SetGWorld() to the GWorld.
:2) Open a picture.
:3) Use CopyBits to copy the picture data on top of itself.
:4) Close the picture.
:5) SetGWorld() back.


        How slow is copying Bits to PICT compared to normal copyBits
without writing it to a PICT ?

        If we changed step (3) to Copying bIts to another GWorld
instead back to itself, are we doing 2 things at the same time ?
One to the PICT handle, another to the other GWorld.

Hee Kiang

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 1 Oct 1995 20:50:53 GMT
Organization: Ecole Normale Superieure, Paris

In article <44i975$[e-mail]>,
PANG HEE KIANG <[e-mail]> wrote:

>       How slow is copying Bits to PICT compared to normal copyBits
>without writing it to a PICT ?

If my understanding of picture recording is correct, when you call
OpenPicture, the QuickDraw bottlenecks are replaced with recording
routines, so calling CopyBits doesn't call the usual, trusty
CopyBits; instead it calls a routine which records the image data
into a picture. The destination bitmap is ignored.

Not 100% sure but it sounds logical to me...

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Frank Durgin, et al.)
Date: Fri, 29 Sep 1995 13:05:57 -0400
Organization: Swarthmore Visual Perception Lab

In article <[e-mail]>, [e-mail]
(Adam Lloyd) wrote:

> So, is it possible to save a GWorld as a PICT file? And if so, could anyone
> give me any pointers to where I can find information on this?

Yep. Do something like this (you might want to chop it up into multiple
routines depending on how you will be using it; this is just more compact
since I don't have to include parameter-passing code ;)

OSErr MakeAndPutPictToFile(ConstStr255Param fileName, GWorldPtr
theWorld)       {
        StringPtr               volName;
        PicHandle               thePict;
        PixMapHandle            thePixmap;
        long                    count;
        unsigned char*          header;

        ConstStr255Param        prompt = "\pSave file as:",
                                defaultName = "\poffscreen PICT";
        OpenCPicParams          picHeader;
        short                   refNum;
        StandardFileReply       reply;
        long                    theDirID;
        Rect                    theOffRect,thePictRect;

        OSErr                           myErr;


        // set up the neccessary PICT header info
        picHeader.srcRect = gMainWindow->portRect;
        picHeader.hRes = 72 << 16;
        picHeader.vRes = 72 << 16;
        picHeader.version = -2;

        thePixmap = GetGWorldPixmap(theWorld);

        // create the Pict
        //      (OpenCPicture turns on recording of QuickDraw calls)
        thePict = OpenCPicture(&picHeader);
                // CopyBits the pixmap to itself: since we're recording draw
                // commands, this will stuff the pixmap data into the pict
                CopyBits((BitMapPtr) *thePixmap, (BitMapPtr) *thePixmap,
                                &theWorld->portRect, &theWorld->portRect,
                                srcCopy, nil);
        ClosePicture(); // stop recording: we have the data

        HLock((Handle)(Handle)thePict); // lock the PicHandle down just in case

        // prompt for a name to save the PICT file under
        StandardPutFile(prompt, defaultName, &reply);
        // if we were successful, create the file
        if(reply.sfGood) myErr = FSpCreate(&reply.sfFile, '????',
                        'PICT', reply.sfScript);
        // and open its data fork
        //      refNum will contain the file reference number at exit.
        if(myErr == noErr)      myErr = FSpOpenDF(&spec, fsRdWrPerm, &refNum);

        // generate an empty 512B header for the PICT
        header = (unsigned char*) NewPtrClear(512);

        // now write the actual data
        if(myErr == noErr ) {
                count = 512L;
                // write the header (in this case, 512 bytes of zeros)
                myErr = FSWrite(refNum, &count, header);
                if(myErr == noErr) {
                        count = GetHandleSize((Handle)thePict);
                        // write the actual data
                        myErr = FSWrite(refNum, &count, *thePict);
                }
                myErr = FSClose( refNum );
                // after closing up, flush the disk caches to make everything
                // update properly
                if(myErr == noErr)      myErr = GetVol(volName, &refNum);
                        // refNum is now the *volume* reference number:
                        //      don't get the two confused
                if(myErr == noErr)      myErr = FlushVol(volName, refNum);
        }

        HUnlock((Handle)thePict);       // unlock the PicHandle
        KillPicture( thePict );         // and dispose of it

        return(myErr);
}


Ta,
        -Stephen

--
Frank Durgin & various student (and recent alumna/us) researchers
- --------------------------
Visual Perception Laboratory
Department of Psychology
Swarthmore College

+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Tue, 03 Oct 1995 23:21:03 -0700
Organization: Best Internet Communications

In article <44muvd$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

>In article <44i975$[e-mail]>,
>PANG HEE KIANG <[e-mail]> wrote:
>
>>       How slow is copying Bits to PICT compared to normal copyBits
>>without writing it to a PICT ?
>
>If my understanding of picture recording is correct, when you call
>OpenPicture, the QuickDraw bottlenecks are replaced with recording
>routines, so calling CopyBits doesn't call the usual, trusty
>CopyBits; instead it calls a routine which records the image data
>into a picture. The destination bitmap is ignored.

You're correct; while drawing a picture, nothing is actually drawn.
However, making a picture will probably still be slower than drawing to
the screen, maybe much so. The data still has to be copied, after all, and
in a picture, it goes into a handle (which can cause memory manager
activity when it has to be grown, etc.) and pixel data gets compressed.

Also, OpenPicture() doesn't replace the bottlenecks; it just calls
HidePen(); so if you want to record and draw at the same time, you can do
it by calling ShowPen() after OpenPicture(). Note that you'll need to do a
balancing HidePen() to match the ShowPen() that ClosePicture() will do.

 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

---------------------------

>From [e-mail] (Bob Williams)
Subject: [Q] How to use SetDialogTracksCursor()
Date: 1 Oct 95 23:08:27 -0500
Organization: Enterprise Software

Can anyone tell me how to use SetDialogTracksCursor? I can use
SetDialogCancelItem and SetDialogDefaultItem without a problem, but not
SDTC. The cursor changes but it seems like the coordinates the system are
checking are global instead of local (i.e., the cursor changes while it is
above and to the left of where it should change). Help?

TIA.

Regards,
Bob
--
Robert E. Williams, Jr. | I can picture a world without war, a world
Macintosh Developer     | without hate. And I can picture us attacking
Enterprise Software     | that world, because they'd never expect it.
______________________________________________________________________
[e-mail]             [e-mail]
[e-mail]               http://miavx1.muohio.edu/~williar2

+++++++++++++++++++++++++++

>From [e-mail] (Jochen Lippert)
Date: Mon, 02 Oct 1995 17:55:23 +0000
Organization: University of Bremen

In article <1995Oct1.230827@miavx1>, [e-mail] (Bob
Williams) wrote:

> Can anyone tell me how to use SetDialogTracksCursor? I can use
> SetDialogCancelItem and SetDialogDefaultItem without a problem, but not
> SDTC. The cursor changes but it seems like the coordinates the system are
> checking are global instead of local (i.e., the cursor changes while it is
> above and to the left of where it should change). Help?
>
> TIA.
>

If you set the current port to the Dialog window, all will work fine:

GetPort(&savePort);
SetPort(myDialog);
SetDialogTracksCursor(myDialog, true);

(Do Dialog stuff here)

SetPort(savePort);

HTH

Jochen Lippert

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (James W. Walker)
Date: Mon, 02 Oct 1995 21:12:34 -0700
Organization: Nisus Software

In article <1995Oct1.230827@miavx1>, [e-mail] (Bob
Williams) wrote:

> Can anyone tell me how to use SetDialogTracksCursor? I can use
> SetDialogCancelItem and SetDialogDefaultItem without a problem, but not
> SDTC. The cursor changes but it seems like the coordinates the system are
> checking are global instead of local (i.e., the cursor changes while it is
> above and to the left of where it should change). Help?

Is the port set correctly?  My usual sequence is:
1. Create the dialog, but the DLOG makes it initially invisible.
2. Call SetPort.
3. Do SetDialogTracksCursor and other initializations.
4. Show the dialog.
5. Call ModalDialog.
--
 Jim Walker

---------------------------

End of C.S.M.P. Digest
**********************